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Abstract 



An ad-hoc wireless network is a collection of nodes that come together to dynamically 
create a network, with no fixed infrastructure or centralized administration. An ad-hoc 
network is characterized by energy constrained nodes, bandwidth constrained links and 
dynamic topology. With the growing use of wireless networks (including ad-hoc networks) 
for real-time applications, such as voice, video, and real-time data, the need for Quality 
of Service (QoS) guarantees in terms of delay, bandwidth, and packet loss is becoming 
increasingly important. Providing QoS in ad- hoc networks is a challenging task because 
of dynamic nature of network topology and imprecise state information. Hence, it is 
important to have a dynamic routing protocol with fast re-routing capability, which also 
provides stable route during the life-time of the fiows. 

In this thesis, we have proposed a novel, energy aware, stable routing protocol named. 
Stability-based QoS-capable Ad-hoc On-demand Distance Vector (SQ-AODV), which is 
an enhancement of the well-known Ad-hoc On-demand Distance Vector (AODV) routing 
protocol for ad-hoc wireless networks. SQ-AODV utilizes a cross-layer design approach 
in which information about the residual energy of a node is used for route selection and 
maintenance. An important feature of SQ-AODV protocol is that it uses only local infor- 
mation and requires no additional communication or co-operation between the network 
nodes. SQ-AODV possesses a make-before-break re-routing capability that enables near- 
zero packet drops and is compatible with the basic AODV data formats and operation, 
making it easy to adopt in ad-hoc networks. 

We demonstrate, through extensive simulation results in NS-2, that the increased 
route stability afforded by SQ-AODV leads to substantially better QoS performance. 
Our results show that under a variety of applicable network loads and settings, SQ- 
AODV achieves packet delivery ratio, on average, 10-15% better than either AODV or 
Minimum Drain Rate (MDR) routing protocol, and node expiration times 10-50% better 
than either AODV or MDR, with packet delay and control overhead comparable to that 
of AODV. 
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Chapter 1 
Introduction 



1.1 Background 

An ad-hoc wireless network is a collection of nodes that come together to dynamically 
create a network, with no fixed infrastructure or centralized administration as shown in 
Figure 1.1. For a source to send data packets to a destination that is not in its direct range 
of transmission, the packets must be relayed through one or more intermediate nodes. For 
example, in Figure 1.1, if node A wishes to communicate with node F that is outside of 
A's direct transmission range, the packets will have to be relayed either through nodes B 
and E or through nodes B and C. Hence, a node must act both as a host and a router. 
A routing protocol is, therefore, required to find the best possible route to relay a packet 
to its desired destination. Two key functions of such a routing protocol are: 

• Determination of routes for various source-destination pairs 

• Delivery of data packets to their correct destination 

Even if the nodes in the ad-hoc network are stationary, the quality of the wireless 
links between them varies - both due to the varying amounts of interference created by 
the transmissions in the network, and due to the variability of the wireless link. Thus, 
a dynamic routing protocol (as opposed to a set of static routes) is required to find the 
best possible route to relay a packet to its desired destination. 

Ad-hoc networks have a number of applications today, due to their ability to provide 
an instant network infrastructure to support communications in temporary or mobile en- 
vironments. For instance, an ad-hoc network is ideal for a battlefield scenario to form 
a command, control, and communications network for tactical military communications. 
Another example is the ability to establish a commercial and educational use network in 
remote areas, where traditional communication infrastructure is non-existent, infeasible 
or expensive. Since ad-hoc networks can be setup on-demand, with no constraint on 
connectivity/topology, they also offer unique benefits for applications such as city surveil- 
lance networks or networks for law enforcement or rescue/disaster management. In each 



1 




Figure 1.1: A Simple Ad- Hoc Network with 9 Participating Nodes 

of these apphcations, the network in question may be static or semi-static, with different 
types of data riding on it. 

With the growing use of wireless networks (including ad-hoc networks) for real-time 
applications, such as voice, video, and real-time data, the need for Quality of Service 
(QoS) guarantees in terms of delay, bandwidth, and packet loss is becoming increasingly 
important. This is particularly challenging for ad- hoc networks, where the nodes are 
invariably constrained by energy. Moreover mobility and the time- varying shared wireless 
medium makes QoS provisioning much more difficult. A key to enabling QoS guarantees 
in ad-hoc networks, therefore, is a dynamic routing protocol that can adapt quickly to 
network changes. 

Existing routing protocols for ad-hoc networks may be broadly classified into: table- 
driven [2] [3] and on-demand [4] [5] protocols. Table-driven protocols are proactive, i.e., 
they try to keep up-to-date routing information about the entire network through periodic 
update messages, and can incur significant overhead in many cases. The on-demand 
protocols, on the other hand, are reactive, i.e., they discover routes as and when required 
by the sources. Since resources in ad-hoc networks are often scarce, on-demand protocols 
appear to be more suitable for such networks. 

1.2 Related Work 

Standard QoS architectures proposed for the Internet, such as the Integrated Services 
(IntServ) model [6] or the Differentiated Services (DiffServ) model [6] are not directly 
applicable to ad-hoc networks, because they were not designed with the wireless environ- 
ment in mind. Given the growing importance of QoS in wireless networks, over the last 
few years, a number of works have proposed ways to improve QoS in an ad-hoc wireless 
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In [7], the authors proposed an extension to Ad- Hoc On-demand Distance Vector 
(AODV) [4] routing protocol to support QoS, assuming the availabihty of some stationary 
hnks in the network. The authors introduced the notion of node stability, based on a node's 
history, which incorporated both, a node's mobihty and its packet processing ratio. Only 
stable nodes were considered for routing. However, the authors did not consider the 
impact that unpredictable link failures would have on re-routing. 

In [8] the authors proposed a Quality-of-Service aware Source initiated Ad-hoc Routing 
(QuaSAR) protocol, which adds QoS control mechanisms to all phases of source routing. 
The protocol maintains an estimate of the battery power required by the application, and 
uses that in the path selection process, while attempting to give guarantees on the latency 
and bandwidth of a flow. The route is selected by the source, after collecting statistics 
on all possible routes that satisfy a flows latency, bandwidth, and power requirements. 
Energy consumption in routing a flow is minimized by choosing the "shortest" path, by 
mapping signal strength to distance. A characteristic of QuaSAR is that it effectively 
trades reduced packet drops for increased protocol overhead. The route request messages 
in QuaSAR must carry latency, bandwidth, signal strength, and battery power informa- 
tion for all nodes along the path to enable the selection of a path that satisfies the QoS 
requirements of a session. QuaSAR requires deploying a completely new protocol, and 
suffers from poor scalability, since source routing can cause the length of route request 
and route reply messages to become excessive in larger networks. Furthermore, the basic 
QoS capabilities of QuaSAR are examined for a rather limited scenario, with only a single 
source and single (mobile) destination. 

In [9] authors have proposed a stable, weight-based, on-demand routing protocol. The 
difference with QuaSAR is that instead of carrying the different parameters themselves, 
the authors use them to compute a composite "weight", which is the one carried in the 
protocol messages. The weight used to select stable routes is based on three components: 
Route Expiration Time (RET), which is the predicted time of link breakage between two 
nodes due to mobility. Error Count (EC), which captures the number of link failures due to 
mobility, and Hop Count (HC). The authors have assumed that all nodes are synchronized 
via a Global Positioning System (GPS), so that two adjacent nodes may predict the 
RET. While the proposed scheme may combat against link breaks due to mobility, link 
breaks due to the draining node energy is a factor that also must be accounted for when 
computing weights for stable routing. 

In [10], the authors have proposed a stable route selection scheme based on Link 
Expiration Time Threshold {LETth)- The Link Expiration Time {LET) is computed 
based on a prediction of neighbor mobility. LET computation needs to know the position 
of the neighbors, and hence requires periodic topology updates. However, the authors 
have not considered the impact that unpredictable link failures would have on re-routing. 

In [1], the authors proposed a new metric, Energy-Drain- Rate (EDR), which is defined 
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cost function is defined as: 

Cr = minT^{t), 

where, 

wliere, DRi{t) is the drain rate of node i at time t and -Erl^) is the residual battery power 
of node i at time t. 

Thus the hfe-time of a path is determined by the minimum T^{t) along that path. The 
Minimum Drain Rate (MDR) [1] mechanism selects the route with maximum life-time. 
Each node monitors its energy consumption during a given past interval r and maintains 
the drain rate value using an exponential weighted moving average. The proposed MDR 
algorithm attempts to select the best possible stable route for a given source and des- 
tination. The periodic route update used in MDR, however, soon becomes costly, as it 
increases control overhead and degrades performance at higher network loads. 

From the proposals reviewed so far [7], [9], [10], [1] it is clear that there is a need for a 
stable routing protocol that can provide stability to the routes selected for routing QoS- 
enabled applications, and also has mechanisms for fast re-routing to tackle unpredictable 
link breakages. Furthermore, for the scheme to be scalable, the stability should come at 
minimum or no overhead. 



1.3 Contributions of the Thesis 

A key to providing QoS guarantees in ad-hoc networks is to find, not just any route to 
the desired destination, but rather a route that can, with high probability, survive for 
the duration of the session. This ensures that communication once initiated will not be 
disturbed. It is also useful to have a mechanism to quickly find an alternate route, if one 
exists, for the session, in case of unpredictable link failure. 

In this thesis, we have proposed an energy-aware on-demand routing protocol which 
also provides stable routes to the flows during their life-time to support QoS in ad-hoc 
networks. The proposed energy-aware, stable routing protocol named. Stability-based 
QoS-capable Ad-hoc On-demand Distance Vector (SQ-AODV) protocol is an enhance- 
ment of the well-known AODV [4] protocol for ad-hoc wireless networks. SQ-AODV 
utilizes a cross-layer design approach in which information about the current residual 
energy, average energy drain-rate of a node, and the session-duration (if known) of the 
application is used to find a stable route. SQ-AODV also does a proactive route mainte- 
nance using "make-bef ore-break" mechanism for finding an alternate route for the session 
when the energy drain rate of a node suggests that it will cease forwarding before the 
session is completed. Since SQ-AODV uses only local information and requires no addi- 
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delivery ratio in the network at virtually no overhead making it more suitable for ad-hoc 
wireless environment. 

1.4 Organization of the Thesis 

The thesis consists of 5 chapters. Chapter 1, gives a brief introduction to wireless ad- 
hoc networks, and need for QoS support and dynamic routing protocol in wireless ad- 
hoc networks. Some of the proposed QoS and stability-based routing protocols are also 
reviewed in this chapter. Chapter 2, gives a brief introduction to AODV routing protocol, 
which we have modified to realize SQ-AODV in NS-2 [11]. A detailed description and 
operation of SQ-AODV is presented in Chapter 3. In Chapter 4, we have given a complete 
details of our simulation scenarios, results along with discussions. Finally, Chapter 5 give 
the summary of the thesis along with some of the future works. 
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Chapter 2 



Ad-Hoc On-demand Distance Vector 
(AODV) Routing Protocol 

In this chapter, we give a very brief introduction to AODV [4], which we have modified in 
designing SQ-AODV. Since the phases of operation of SQ-AODV remain the same as those 
of AODV, it is important to first understand the basic operation of AODV. AODV is a 
destination-based reactive protocol It avoids routing loops by tagging an unique sequence 
number to route information for each destination. This sequence number is generated or 
originated by the destination. AODV for its operation assumes symmetric links between 
neighboring nodes. That is, the links are bidirectional, and should have same properties 
in both directions. AODV routing protocol uses different routing messages to discover 
the routes and maintain links. 

• RREQ is a route request message used whenever a new route to a destination is 
required. 

• RREP is a reply message for a route request. 

• Periodic HELLO messages are broadcast to check the presence of immediate active 
neighbors. 

If a node does not lie along an active route, it neither maintains routing information 
nor participates in the exchange of routing information. The protocol consists of two 
basic processes: 

1. Path discovery 

2. Path maintenance 

2.1 Path Discovery 

A path discovery process is initiated whenever a source node needs to send data packets 
to a destination node and does not have a route information for this destination node. 
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G and does not have a route information. Then node A initiates a route discovery process 
by broadcasting a RREQ packet to its immediate neighbors (in our case node B). Each 
intermediate node after receiving the first RREQ packet does the following: 

• Checks whether it has a current route information about the destination node 

• If it has a current route information, it sends a RREP back to the source node 

• If it does not have a current route information, it rebroadcasts the RREQ to its 
neighboring nodes and keeps a record of the following information for setting up a 
reverse path: 

— Destination IP address 

— Source IP address 

— Broadcast ID 

— Expiration time for the reverse path entry 

— Source node sequence number 

Every subsequent RREQ (copies) with the same broadcast ID is discarded. In our case 
assume node B rebroadcasts the RREQ to its immediate active neighbors A, C and E and 
keeps a record. Node C after receiving RREQ rebroadcasts the RREQ to its immediate 
neighbors B, D, E and F, and keeps a record. Node D simply times out because its only 
neighbor is node C from which it has received RREQ. All intermediate nodes repeat this 
operation of either rebroadcasting or timing out till RREQ reaches the final destination. 
Finally, when RREQ reaches the desired destination node G, the node will unicast a 
RREP message back to the source through the reverse path setup. 

2.1.1 Reverse Path Setup 

A source sequence number is used to maintain freshness information about the reverse 
path to the source. In Figure 2.1, RREQ travels form node A to various active inter- 
mediate nodes and when it finally reaches the destination node G, it automatically sets 
up the reverse path from the destination to source. To do this reverse path setup every 
intermediate node (in our case nodes B and E) records the address of the active neighbor 
from which it received the first copy of the RREQ. These reverse path entries are main- 
tained for sufficient amount of time so that the RREQ packet traverses the network and 
produce a reply back to the source. The reverse path that is setup from node E to node 
A is indicated by solid arrows in Figure 2.1. 
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■ ■ ■► Path of RREQ packets 
^ Reverse path setup 



Figure 2.1: Reverse Path Setup in AODV 




Path of RREP packets 
>- Forward Path setup 



Figure 2.2: Forward Path Setup in AODV 



8 



As the RREP travels back to the source using a reverse route, either from the destination 
node or an intermediate node that has a current route information about the destination, 
each node along this reverse path sets up a forward pointer to the node from which 
the RREP is received. Each node also updates the timeout information for this source 
to destination, and records the latest destination sequence number. In Figure 2.2 solid 
arrows indicate the forward path from node A to node G. This path is setup with the help 
of forward pointers as the RREP travels back from destination node G to source node A. 
The nodes that are not active along the path determined by the RREP will timeout and 
delete the reverse pointers. Once the forward path is setup and the RREP reaches the 
source node A, source node A will immediately start data transmission. 

2.1.3 Route Table Management 

Apart from the source and destination sequence numbers as entries in the routing table, 
there are expiration timers associated with reverse path entries and route invalidation. 
The purpose of the timer meant for reverse path entry is to give timeout information 
for purging of those reverse path entries in the nodes that do not lie along the path 
determined by RREP. In Figure 2.1 nodes C, D, F, H and I purge there entries after this 
timer expiration. This expiration time depends on the size of the ad-hoc network. There 
is another expiration timer which is used to invalidate a route already available in the 
cache. A neighbor is considered to be active, if it originates or relays at least one packet 
for that destination in the timeout period and the address of the active neighbors is also 
entered in the table. Hence a node maintains the fallowing information for each route 
table entry: 

• Destination IP address 

• Next hop 

• Number of hops 

• Sequence number for the destination 

• Active neighbors for that route 

• Expiration time for the route table entry 

If there is more than one route entry for a particular destination, the node chooses the 
one with higher sequence number. If the sequence numbers are same then a route with 
smaller metric (less number of hop count) is chosen. 
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If a node moves from the current location to a new location in the network, the routing 
will not be affected unless this node was in the active routing path. When a source node 
moves to a new location in the network and affects the route of an active session (i.e., 
before route invalidation timer expires), then the source can re-initiate a route discovery 
procedure if a route to the desired destination is still required. On the other hand, if 
an intermediate node of an active session moves from its present position, then a special 
RREP is sent to the affected source nodes. Periodic HELLO messages are used to detect 
link failures. Link failures can also be detected if a node is unable to forward a packet to 
the next hop. Once a link failure is detected, an unconditional RREP with fresh sequence 
number and hop count set to infinity is broadcast to active neighbors. Within some time 
all active nodes in the network will know about link failure. The source nodes can restart 
the discovery process if they still need a route to a destination. 

2.2.1 Local Connectivity Management 

Nodes learn about their neighbors in two ways. One way is whenever a node receives 
a broadcast message from a neighbor it updates its local connectivity. Other way is to 
broadcast HELLO messages to its active neighbors. If a node does not receive HELLO 
messages consecutively, this indicates that local connectivity is changed. 
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Chapter 3 

Stability-based QoS-capable AODV 



In this chapter, we present our energy-aware on-demand routing protocol SQ-AODV. We 
explain the operation of SQ-AODV along with the cross-layer design used to implement 
the protocol in NS-2 [11]. 

3.1 Introduction 

SQ-AODV is an enhancement to the well-known AODV [4] routing protocol, which we 
have discussed in Chapter 2. The enhancements are done in both Path Discovery and 
Path Maintenance phases of AODV to make it a stable and dynamic routing protocol. 
The two main features of SQ-AODV are it: 

• Provides stable routes by accounting for the residual life-time at intermediate nodes 
(calculated using the current Average-Energy-Drain- Rate (AEDR)) and the dura- 
tion of the session (if known) at the route selection stage. 

• Guards against link breakages that arise when the energy of a node(s) along a path 
is depleted, by performing a make-before-break re-route (where possible). This 
minimizes packet loss and session disruptions. 

The first feature ensures that SQ-AODV only routes sessions along routes that either 
have intermediate nodes with sufficient energy to last the length of the session or along 
routes that maximize the residual life-time of the bottleneck node, thus ensuring, with 
very high probability, that session disruption due to energy depletion at an intermediate 
node does not occur. It turns out that this increased stability leads to substantially 
better QoS in terms of packet delivery ratio (PDR) and packet delay (PD), even without 
explicitly accounting for bandwidth, jitter or delay requirements, as our subsequent results 
demonstrate. 
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imminent, SQ-AODV proactively re-routes sessions, without losing any packets. Once 
again, this provides near-zero packet loss and superior QoS performance. 
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Figure 3.1: Cross-layer Design Used in SQ-AODV 

The operation of SQ-AODV utilizes the cross-layer design depicted in Figure 3.1, 
where energy information from the physical layer is used in admission control decisions at 
the network layer and to turn-off sessions at the application layer. We now explain these 
two features in more detail. 

3.1.1 Path Discovery 

The first modification/feature is outlined in Algorithm 1, and helps in choosing an ap- 
propriate sequence of intermediate nodes for the requesting session. 

Algorithm 1 : Selection of an Intermediate Node as Router 
1: An intermediate node N receives a RREQ; 
2: if Session-Duration is specified in the RREQ then 
3: Check 

4: if Current- Energy > {Session-Duration x AEDR) then 

5: Update Bottleneck life-time field of RREQ; 

6: ADMIT the session and forward the RREQ to the neighbors 

7: else 

8: REJECT the session, and DROP the RREQ 
9: end if 
10: else 

11: if Current- Energy > Threshold-1 
then 

12: Update Bottleneck life-time field of RREQ; 

13: ADMIT the session and forward the RREQ to the neighbors 

14: else 

15: REJECT the session, and DROP the RREQ 
16: end if 
17: end if 
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generates data packets and transmits them to the network layer. At the network layer, 
the routing protocol responsible for finding a route to the desired destination initiates a 
route discovery procedure, if it does not already have a route for that destination. We 
assume here that, if the session-duration is known, the application layer directly provides 
that to the network layer, as shown in Figure 3.1. If not, each intermediate node uses 
a heuristic and accepts a session only if it has at least Threshold-1 of residual life 
(Threshold- 1 is the residual energy of a node with which the node is alive for the next 
X seconds at current AEDR, in our implementation X = 5 seconds). 

The source broadcasts Route Request (RREQ) packets to its neighbors when it has 
no route to the desired destination. When a RREQ packet reaches an intermediate node. 
Algorithm 1 queries the physical layer for the current residual energy, and checks whether 
the residual energy at the current AEDR is sufficient to last the duration of the fiow. 
The session is only admitted if that is the case. If the session-duration is unknown, the 
algorithm admits the session only if the residual energy at the node is above Threshold-1. 
Before forwarding, the node updates the bottleneck life-time field of the RREQ packet. 

The Energy-Drain-Rate (EDR) is computed as a difference between the energy En of 
the node at periodic intervals divided by the length of the interval. Thus, 

EDR(t2) = 

where En{ti) and En{t2) are energy levels of the node at times ti and t2 respectively. 
Finally, this EDR is averaged using exponential averaging with a = 0.5 to compute the 
AEDR as follows: 

AEDR(t) = a X EDR(t) + (1-a) x AEDR(t-l). 

Finally, when the RREQ packets reach the destination, it picks a route that maximize 
the route life-time by selecting the one with maximum life-time of the bottleneck node. 

3.1.2 Path Maintenance 

The second modification/feature helps the routing protocol to adapt quickly to imminent 
link breakage likely to occur when the energy of a node is fully drained. The algorithm for 
this is depicted in Algorithm 2. Since the physical layer keeps track of the AEDR, it sends 
an alarm to the network layer shortly before it is about to drain completely i.e., when 
the current energy of the node is less than Threshold-2 (Threshold-2 is the residual 
energy of a node with which the node is alive for the next Y seconds at current AEDR, 
in our implementation Y = 1 second). The routing protocol adapts to this event, and its 
behavior depends on whether the node is an intermediate node (I) or a destination node 
fD). 
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sends a Route Change Request (RCR) packet to all source nodes using it as an intermedi- 
ate hop towards their respective destinations. The source upon receiving the RCR packet, 
begins a new route discovery procedure for the session, and thus, with high probability, 
finds a new route before an actual link break occurs on the original route, leading to 
the make-bef ore-break behavior. This reduces packet drops due to link breakage and the 
consequent delay incurred, and enables the routing protocol to quickly adapt to network 
changes, if an alternate path to the desired destination exists. If the node being drained 
is a destination node, it sends a request to the source to stop all traffic transmission to 
itself. When the request reaches the source, the network layer sends a stop signal to the 
application, as shown in Fig. 3.1, preventing further transmission of data. This reduces 
the number of packet drops in the network and increases packet delivery ratio, and re- 
duces resource usage by avoiding packet transmissions to unavailable destinations. If a 
source node itself is about to drain, it simply continues to transmit data until it cannot 
transmit anymore. 

Algorithm 2 : Route Maintenance by Make-before-break 
1: Node N periodically compute the EDR and check for Current- Energy; 
2: if Current- Energy < Threshold-2 

then 
3: Check 
4: if N == I 
then 

5: Send RCR to all the source nodes using this node as router 
6: end if 
7: if N == D 
then 

8: Send a Stop-TrafRc request to all sources that are communicating with this 

destination 
9: end if 
10: end if 



Note that SQ-AODV uses only local information, and requires no additional commu- 
nication or co-operation between the nodes. Indeed, the algorithms described above could 
be used with any underlying routing protocol, but we use AODV protocol as it is one of 
the most popular ad-hoc routing protocols. 
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Chapter 4 

Simulation Experiments, Results and 
Discussions 

In this chapter, we present and discuss a wide range of results of extensive simulations that 
we have conducted in NS-2 [11] (Version 2.30), to compare the performance of SQ-AODV 
with that of MDR [1] and AODV [4]. We have considered the following six parameters: 

• Packet Delivery Ratio (PDR): is the ratio of the number of packets successfully 
received by all destinations to the total number of packets injected into the network 
by all sources. The PDR is therefore a number between and 1. 

• Normalized Control Overhead: is the ratio of number of routing packets trans- 
mitted (hop wise) by all the nodes to the total number of packets successfully 
received by all destinations in the network. The normalized control overhead is 
therefore a number greater than 0. 

• Average Packet Delay: is the sum of the times taken by the successful data 
packets to travel from their sources to destinations divided by the total number of 
successful packets. The average packet delay is measured in seconds. 

• Average Hop Count: is the sum of the number of hops taken by the successful 
data packets to travel from their sources to destinations divided by the total number 
of successful packets. The average hop count is measured in number of hops. 

• Node Expiration Time (NET): is the time for which a node has been alive 
before it must halt transmission due to battery depletion. The node expiration time 
is plotted as number of nodes alive at a given time, for different points in time 
during the simulation. 

• Connection Expiration Time (CET): is the time for which a connection has 
been active before it must cease transmission due to the non-availability of a route 
between source and destination. This occurs when nodes along the path expire or 
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expressed in seconds. 
We present our simulation results in 3 different parts, and are as follows: 

1. Demonstration of SQ-AODV features 

2. Validation of MDR [1] implementation 

3. Performance comparison of SQ-AODV, MDR and AODV [4] 

4.1 Demonstration of SQ-AODV Features 

In this section, we present our simulation results to demonstrate the energy awareness 
and make-before-break re-routing features of SQ-AODV by comparing the packet delivery 
ratio performance with that of AODV. 

4.1.1 Simulation Setup 

We have considered the 12-node topology in 500 m x 1000 m area as shown in Figure 4.1. 
The nodes are identical in their capability, but are initialized with different energies in 
different experiments Exptl to ExptS, that we have conducted, and there is no mobility 
in the network. 

To calibrate the load that can be supported by the network, an extensive series of 
simulations with one, two, three, and five simultaneous sessions was conducted with vary- 
ing average session data rates. We found that when the aggregate rate of sessions at the 
nodes exceeded about 225 Kbps on average, the packet drop rate in the network became 
excessive, indicating that the network was saturated beyond capacity. We have thus used 
this rate as 100% load, and normalized using this. 

The MAC layer protocol is IEEE 802.11 DCF (Distributed Co-ordination Function) 
with the PLCP (Physical Layer Convergence Protocol) data rate being 1 Mbps. The 
parameters used in the simulations for Exptl to Expt5 are listed in Table 4.1. 

Here we demonstrate the PDR performance of SQ-AODV under a variety of different 
network loads and node energies, and assess the benefit of its make-before-break strategy. 
In each experiment Exptl to ExptS, the initial energy levels of the nodes is randomly 
chosen between 10 Joules to 100 Joules, and compared the performance of PDR for SQ- 
AODV and AODV. The starting times of the sessions were chosen such that there were 
at most between 3-5 sessions in parallel in the network at any instant. The network load 
was varied from about 20% to 90%, so the session data rate is varied from 15 Kbps to 65 
Kbps (3-5 sessions of 15 Kbps each equates to 20% of 225 Kbps (225 Kbps equals 100% 
load) and 3-5 sessions of 65 Kbps each equates to 90% of 225 Kbps). Each experiment is 
run 50 times (each initialized with different seed), and the resulting PDR is averaged over 
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T 1000 




Figure 4.1: 12 Node Topology 



Table 4.1: Values of Parameters Used for the Simulation of the 12 Node Topology 



Packet size 


512 Bytes 


Packets/Session 


1000 


Date traffic 


Poisson with exponential 
inter-arrival time 


MAC Protocol 


IEEE 802.11 DCF 


PCLP Data rate 


1 Mbps 


Buffer length 


50 Packets 


Transmit power 


0.2818 W 


Propagation model 


Two-Ray Ground 
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generated as per a Poisson process. The energy distribution of the nodes for each of the 
5 experiments Exptl to ExptS, as well as the source-destination pairs for each session are 
summarized in Table 4.2 and Table 4.3, respectively. 

Table 4.2: Initial Energy of Nodes for Each Experiments in Joules 



Node 


Exptl 


Expt2 


Expt3 


Expt4 


Expt5 


1 


45 


29 


94 


82 


93 


2 


20 


91 


40 


73 


39 


3 


24 


40 


29 


37 


64 


4 


62 


97 


87 


33 


31 


5 


59 


82 


73 


90 


73 


6 


93 


82 


50 


30 


35 


7 


85 


50 


87 


64 


100 


8 


68 


34 


54 


28 


19 


9 


24 


15 


24 


86 


61 


10 


30 


17 


18 


86 


49 


11 


55 


43 


35 


90 


87 


12 


39 


20 


95 


11 


97 



Table 4.3: Source-destination Pairs in the 12 Node Topology 



Session No. 


{src, dst] 


1 


{1, 11} 


2 


{2, 12} 


3 


{3, 11} 


4 


{8, 6} 


5 


{10, 1} 


6 


{2, 4} 


7 


{12, 3} 


8 


{4, 2} 


9 


{11, 1} 


10 


{7, 6} 


11 


{8, 10} 


12 


{12, 1} 



4.1.2 Results and Discussions 

The packet delivery ratio for each of the experiments Exptl to Expt5, for both SQ-AODV 
and AODV [4] is plotted in Figures 4.2 - 4.6. It can be observed that, in all cases, and for 
all loads, the packet delivery ratio is improved substantially, and SQ-AODV outperforms 
AODV. This is because there are some nodes whose battery life is limited. Choosing 
these nodes as intermediate nodes, as is done by AODV, leads to disconnections in the 
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Figure 4.2: Packet Delivery Ratio for EXPTl 
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Figure 4.3: Packet Delivery Ratio for EXPT2 



19 



EXPT3 




CD 0.4 - 
O 

S. 0.3 - 



0.2 - 



0.1 - 



-o- 


SQ-AODV 




AODV 


— B— 



3 1 1 1 1 1 1 

15 25 35 45 55 65 

Session data rate in Kbps 



Figure 4.4: Packet Delivery Ratio for EXPT3 




Figure 4.5: Packet Delivery Ratio for EXPT4 
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Figure 4.6: Packet Delivery Ratio for EXPT5 

session. SQ-AODV, on the other hand, performas better because, (i) it chooses those 
intermediate nodes whose energy is sufficient to support the session for its entire durations 
or it chooses those intermediate nodes which maximize the hfe-time of the route, and (ii) 
its make-bef ore-break strategy that re-routes a session proactively when a hnk failure 
due to depletion of node energy is imminent. Thus, SQ-AODV is successful in reducing 
packet drops in the network drastically. Additionally, in SQ-AODV, the traffic of a source 
is stopped just as a destination is about to drain, leading to saving of network resources, 
by not transmitting packets that would, in any case, not be used by the destination. 

4.2 Validation of MDR Implementation 

In this section we give a brief introduction to the Minimum Drain Rate (MDR) [1] routing 
protocol and its implementation in NS-2 [11]. We also present the simulation results 
to demonstrate the correctness of our implementation. Since MDR is an energy-aware 
routing protocol with a system model and operation quite similar to that of SQ-AODV, 
we have chosen MDR for comparison with SQ-AODV. 

4.2.1 MDR Implementation 

Minimum drain rate is basically a mechanism used to select a path between a source and 
destination that maximizes the life-time of a route. In MDR the life-time of a path is 
dictated by the life-time of the bottleneck node along the path. The life-time of a node is 
calculated using the current Average- Energy-Drain- Rate (AEDR). Each node calculates 
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last T seconds (T = 6 seconds as specified by MDR authors in Section 3 of [1]). Tliis 
computed EDR is averaged using exponential weighted moving average (with a = 0.3 as 
specified by MDR authors in Section 3 of [1]). 

Let DRiit) be the drain rate of node i at time t and El{t) is the residual battery 
power of node i at time t. Thus, the life-time of a path is determined by the minimum 
T^it) along that path, where. 

Tit) = ^^^^^ 

Thus, the Minimum Drain Rate (MDR) mechanism selects the route with maximum 
life-time. 

We have used AODV [4] as the underlying routing protocol and made necessary mod- 
ifications for our MDR implementation. In [1], authors have used Dynamic Source Rout- 
ing (DSR) as underlying routing protocol for implementation of MDR, however authors 
claim that underlying routing protocol does not make a difference in the performance of 
the MDR scheme. Since both DSR and AODV are on-demand routing protocols and we 
have already used AODV for implemention of SQ-AODV, we decided to use AODV for 
MDR implementation. 

For MDR routing protocol implementation, we have modified the RREQ message of 
AODV to carry the bottleneck life-time information of the path. As the RREQ message 
travels from source to destination, the bottleneck life-time field of the RREQ messages 
is updated. The destination node waits either for 0.25 seconds after the first RREQ 
receiption or for the receiption of 3 RREQs, and finally reply to the RREQ that maximizes 
the life-time of the path. MDR updates its routes every 10 seconds to maintain up-to- 
date routing information. Hence a source node keep updating the routes by periodic route 
discoveries. We have simulated the AODV-based MDR, and present the simulation setup 
and the results in the Section 4.2.2 and Section 4.2.3 respectively. 



4.2.2 Simulation Setup 

We consider the 49-node static topology (where there is no node mobility) with 12 ses- 
sions as shown in Fig. 4.7 for our simulations. This is the same dense network scenario 
considered in [1]. The nodes are distributed uniformly in an area of size 540 m x 540 m, 
and are identical in their capability, but are initialized with different energies. The source 
and destinations have higher initial energy than other nodes, this is to make sure that the 
communication between source and destination starts. 

The MAC layer protocol is IEEE 802.11 DCF (Distributed Co-ordination Function) 
with the PLCP (Physical Layer Convergence Protocol) data rate being 1 Mbps. The 
parameters used for these simulations are listed in Table 4.4. The data traffic in all the 
sessions is CBR, with data packets at each node arriving at 3 packets/sec and all the 
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Session #1 : -> 48 Session #2 : 42 -> 6 Session # 3 : 21 -> 27 
Session #4 : 45 -> 3 Session # 5 : 35 -> 41 Session # 6 : 7 -> 13 
Session #7 : 34 -> 28 Session # 8 : 20 ->14 Session # 9 : 43 -> 1 
Session # 10 : 2 ->44 Session # 11 : 4 -> 46 Session # 12 : 47 -> 5 



Figure 4.7: 49 Node Topology with 12 Sessions 

sessions starting at the start of the simulation. Initial energy of the source/destinations 
are chosen randomly between 50 to 75 Joules and that of intermediate nodes are selected 
between 25 to 50 Joules. The simulation was run 50 times (each initialized with a different 
seed), and the resulting parameters are averaged over these 50 runs. 

Table 4.4: Values of Parameters Used for MDR Verification 



Packet size 


512 Bytes 


Simulation time 


800 sec 


Date traffic 


CBR with 3 pkts/sec 


MAC Protocol 


IEEE 802.11 DCF 


PCLP Data rate 


1 Mbps 


Buffer length 


50 Packets 


Ptconsume 


0.2818 W 


PrConsume 


0.2818 W 


Propagation model 


Two-Ray Ground 



4.2.3 Results and Discussions 

The results of Node Expiration Time and Connection Expiration Time, generated with 
our implementation of MDR routing protocol are plotted in Figure 4.8 and Figure 4.9 
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Figure 4.8: Node Expiration Time 




Figure 4.9: Connection Expiration Time 
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Figure 4.10: Node Expiration Time [1] 
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Figure 4.11: Connection Expiration Time [1] 
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for Node Expiration Time and Connection Expiration Time respectively with * sign as 
sample points. Although authors of MDR paper [1] have not given enough information 
to duplicate their results, we have reverse engineered the network parameters to get close 
to their results. We have simulated an AODV-based MDR and the plots in Figure 4.8 
and Figure 4.9 are qualitatively similar to those in origional MDR paper, this verifies the 
behavior of our implementation of MDR is similar to that of original MDR paper. 

4.3 Performance Comparison of SQ- AODV, MDR and 
AODV 

In this section, we present the simulation results to compare the performance of the three 
protocols SQ-AODV, MDR and AODV. For performance comparison, we have conducted 
two set of experiments. Set A and Set B. Set A is designed to evaluate the overall 
performance of SQ-AODV, MDR and AODV, for GBR traffic sources, while Set B is 
designed to evaluate the overall performance SQ-AODV, MDR and AODV, for Poisson 
traffic sources and at varying network loads. We present the results of these 2 sets along 
with the simulation setup in the next section. 

4.3.1 Simulation Setup for Set A 

We consider the 49-node static topology (where there is no node mobility) with 12 sessions 
as shown in Figure 4.7, This is the same dense network scenario considered in [1]. The 
nodes are distributed uniformly in an area of size 540 m x 540 m, and are identical in 
their capability, but are initialized with different energies. 

Table 4.5: Values of Parameters Used for Simulation Set A 



Packet size 


512 Bytes 


Simulation time 


800 seconds 


Date traffic 


CBR with 3 pkts/sec 


MAC Protocol 


IEEE 802.11 DCF 


PCLP Data rate 


1 Mbps 


Buffer length 


50 Packets 


Transmit power 


0.2818 W 


Propagation model 


Two-Ray Ground 



Simulation Set A involves 2 experiments. In the first, all sessions begin transmission 
at the start of the simulation, and the simulation runs for a fixed duration (800 s). In 
the second, the session start times are chosen randomly. In both experiments, the initial 
energy of the nodes is uniformly distributed between 25 J and 100 J, and data at each 
node arrives at 3 pkts/sec or about 12 Kbps. Every experiment was run 50 times (each 



26 



runs. The network parameters used in simulation Set A are detailed in Table 4.5. 
4.3.2 Results and Discussions for Set A 

The results of the two experiments from simulation Set A are presented in Table 4.6, 
while the plots of NET and GET are presented in Figs. 4.12 - 4.15 



Table 4.6: Simulation Results for Set A 



Parameter 


Set-A(l) 




Set-A(2) 






SQ-AODV 


MDR 


AODV 


SQ-AODV 


MDR 


AODV 


PDR 


0.9760 


0.8456 


0.8681 


0.9892 


0.9201 


0.8926 


COH 


0.7742 


13.3207 


1.0877 


0.3402 


4.1554 


0.8256 


PD (sec) 


0.0618 


0.2429 


0.0543 


0.0348 


0.0508 


0.0353 



We see from Table 4.6 that the PDR for SQ-AODV in the two experiments is improved 
by 12.5% and 10.8%, respectively, relative to AODV. This is because choosing nodes with 
limited battery life, as happens in AODV, leads to (avoidable) disconnections of sessions. 
SQ-AODV, on the other hand, performs better because: (i) it chooses those intermediate 
nodes whose energy is sufficient to support the session for its entire duration or it chooses 
nodes to maximize the life-time of the route, and (ii) due to its make-before-break strategy, 
which re-routes a session proactively when link failure due to depletion of node energy 
is imminent. Thus, SQ-AODV successfully reduces packet drops in the network quite 
significantly. 

Similarly, the PDR in MDR in the two cases is poorer by 15.4% and 7.5%, respectively 
as compared to SQ-AODV. This is because MDR's periodic route update feature adds 
substantial routing overhead in the network. In fact. Table 4.6 shows that MDR overhead 
is approximately 17 times and 12 times worse than that of SQ-AODV, respectively, and 
almost 12 times and 5 times worse than that of AODV, respectively. This leads to its 
much lower PDR. 

The packet delay for both SQ-AODV and AODV is comparable in both cases. We 
posit that this is because the delay in SQ-AODV is the result of two opposing factors. 
On the one hand, finding stable routes, where the life-time of the bottleneck node is 
maximized, may lead to longer (but more stable) routes, thus increasing delay. On the 
other hand, proactive route maintenance by way of make-before-break decreases delay, 
since no retransmissions need occur while an alternative route is located. These two 
factors have a compensatory effect, making the packet delay in SQ-AODV of the same 
order as that in AODV. Results in Section 4.3.4 (Table 4.8) demonstrate the compensatory 
effects which makes the delay in SQ-AODV and AODV comparable. MDR, by contrast, 
imposes a much higher load on the network due to its periodic route updates making 
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respectively, the delay for AODV or SQ-AODV. 
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Figure 4.12: NET: Sessions Commence at Start of Simulation 

We see from Figs. 4.12 and 4.13 that in our network setting, running SQ-AODV 
improves the node expiration time by between 25 to 100 seconds over AODV, and by 
between 100 to 150 seconds over MDR. In other words, for a given number of nodes 
alive, this equates to SQ-AODV extending the node life-time by between 10%-25% over 
AODV, and by between 25%-35% over MDR. Viewed another way, at a given simulation 
time, SQ-AODV typically has between 10%-25% more nodes alive than does AODV, and 
has between 20%-60% more nodes alive than does MDR. This is because SQ-AODV's 
proactive route maintenance is very economical of node energy. In addition, due to the 
proactive mechanism in SQ-AODV, a source stops transmitting traffic if a destination 
is about to drain, which saves resources by minimizing the transmission of packets that 
would not have been received by the destination in any case (due to its expiring). The 
nodes in MDR, on the other hand, expire faster than they do in either AODV or SQ- 
AODV by a significant margin, this is because the periodic updates of MDR consume 
energy at a substantially faster rate, causing nodes to expire much quicker, as our results 
demonstrate. 

Figs. 4.14 and 4.15 illustrate that in our network setting, in terms of GET, AODV 
performs better by about 10-50 seconds over both SQ-AODV and MDR. (Note that the 
X-axis in these figures simply indicates the number of connections that have expired, and is 
not the connection identifier . Thus, the connections that expire under each protocol can 
be different. So, for example. Fig. 4.14 shows that 6 connections expire at approximately 
200 seconds with AODV, at 180 seconds with SQ-AODV, and at 165 seconds with MDR. 
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Figure 4.13: NET: Random Session Start Times 
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Figure 4.14: GET: Sessions Commence at Start of Simulation 



29 



txpiraiion oi conneciions 




5 6 7 

Connections 



10 



12 



Figure 4.15: GET: Random Session Start Times 



However, the 6 sessions that expire under each protocol are not the same sessions). 

This equates to AODV connection expiration times being anywhere between 30%-7% 
better than those of SQ-AODV or MDR. This is because, in SQ-AODV: (i) a source on 
receiving an RCR from an intermediate node tries only a fixed (but configurable; in our 
case 3) times before it reaches the maximum number of retries and ends the session, and 
(ii) intermediate nodes reject a new session once its residual-energy is bellow Threshold-1. 
By contrast AODV keeps retrying and so has a higher probability of finding a path, and 
keeping the session alive for longer. In the case of MDR, however, it is the control overhead 
packets that cause the node energy to drain faster, leading to the sessions expiring quicker 
than with AODV or SQ-AODV. We note that the slightly higher connection expiration 
times in AODV do come at the cost of lower PDR and lower node expiration times, which 
implies that even though the connections may be alive for a longer period in AODV, they 
do not successfully transmit as much data as SQ-AODV does. 



4.3.3 Simulation Setup for Set B 

We consider the same 49-node static topology (where there is no node mobility) with 
12 sessions as shown in Figure 4.7 for Set B. The nodes are distributed uniformly in an 
area of size 540 m x 540 m, and are identical in their capability, but are initialized with 
different energies. In this set The traffic arrives as per a Poisson process, for different 
network loads. The initial node energies are uniformly distributed between 75 J and 300 
J, and the simulation is run until each session has transmitted 3000 packets, while the 
session data rates vary from 15 Kbps to 65 Kbps. Here we again examine performance 
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loads. 

Table 4.7: Parameters and Their Values Used for Simulation Set B 



Packet size 


512 Bytes 


Packets / Session 


3000 


Date traffic 


Poisson with A = 15 Kbps - o5Kbps 


MAC Protocol 


IEEE 802.11 DCF 


PCLP Data rate 


1 Mbps 


Buffer length 


50 Packets 


Transmit power 


0.2818 W 


Propagation model 


Two-Ray Ground 



Every experiment was run 50 times (each initialized with a different seed), and the 
resulting parameters averaged over these 50 runs. The network parameters used in simu- 
lation Sets A and B are detailed in Table 4.7. 

4.3.4 Results and Discussions for Set B 

We observe from Fig. 4.16, the PDR of SQ-AODV is substantially better than that for 
AODV or MDR. In fact, the PDR for SQ-AODV is improved by between 25%-13% over 
AODV and by between 22%- 18% over MDR over the network loads considered. The key 
reason for this are the two properties of SQ-AODV discussed in Chapter 3, which induce 
stable routes for the sessions and bolster PDR. 



Average Packet Delivery Ratio 
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Figure 4.16: Average Packet Delevery Ratio for Simulation Set B 
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reduced by equal amount at higher loads because of its extra overhead, which degrades 
MDR performance at higher network loads. 
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Figure 4.17: Average Control Overhead for Simulation Set B 

Fig. 4.17 shows that SQ-AODV has marginally higher normalized control overhead 
(between l%-3% higher) than AODV. This is because, as explained in Chapter 3, to 
support stable routing, SQ-AODV uses per-session (or per-flow) based routing (as opposed 
to simple destination-based routing used in AODV). For this, control packets of SQ-AODV 
carry extra flow-id information along with source and destination, and also packets need 
travel all the way to destination to find a stable path, leading to a marginally higher 
control overhead. 

We see that MDR has the highest control overhead, almost 300% higher than either 
AODV or SQ-AODV at loads above 35 Kbps, rising to over 1000% higher at lower loads. 
This is because of the control overhead of MDR. In particular, at lower loads the control 
overhead of MDR becomes very high, because it takes substantial time for the sources to 
generate 3000 packets. In the meantime, the regular periodic update procedures of MDR 
continue accumulating significant control overhead. 

Finally Fig. 4.18 illustrates that, the delay experienced by packets in SQ-AODV is 
almost the same or marginally better than that in AODV, at all loads under considera- 
tion. This is because the delay in SQ-AODV is the result of two opposing factors. On 
the one hand, finding stable routes, where the life-time of the bottleneck node is maxi- 
mized, may lead to longer (but more stable) routes, thus increasing delay. On the other 
hand, proactive route maintenance by way of make-before-break decreases delay, since 
no retransmissions need occur while an alternative route is located. These two factors 
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Figure 4.18: Average Packet Delay for Simulation Set B 

have a compensatory effect, malting the packet delay in SQ-AODV of the same order as 
that in AODV. The delay experienced in MDR is between 250-500 ms higher, or between 
20%-50% higher than that in AODV and SQ-AODV because, at higher loads data packets 
have to wait longer due to periodic route updates. The advantage with SQ-AODV is that 
it is designed to provide stable routes and a fast re-routing capability to the nodes in 
ad-hoc networks at minimum overhead to the network. This helps in making effective use 
of network resources, as demonstated by our simulation results. 



Table 4.8: Average Number of Hops for Simulation Set B 



Protocol 






Session Data Rate 








15 Kbps 


25 Kbps 


35 Kbps 


45 Kbps 


55 Kbps 


65 Kbps 


SQ-AODV 


4.9503 


5.0165 


5.0519 


5.0487 


5.0938 


5.2244 


MDR 


5.0147 


5.0258 


5.0800 


5.1616 


5.0861 


5.1326 


AODV 


4.5294 


4.4972 


4.5858 


4.6581 


4.6984 


4.7311 



Table 4.8 gives the number of hops taken by the data packets to travel from source to 
destination in SQ-AODV, MDR and AODV, on an average. As we can see the number of 
hops taken by SQ-AODV and MDR is increased by about 11% over AODV on an average 
over all loads. This should clearly indicate that the packet delay in case of SQ-AODV 
would have been more, but the proactive route maintenance by way of make-before-break 
decreases delay in SQ-AODV, leading to an almost similar delay in both SQ-AODV and 
AODV over all loads. On the other hand for MDR, the data packets experience a larger 
delay compared to both SQ-AODV and AODV as explained earlier in Section 4.3.2. 
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Chapter 5 

Summary and Future Work 



In this thesis, we have proposed a novel, energy-aware, stable routing protocol named. 
Stability-based QoS-capable Ad-hoc On-demand Distance Vector (SQ-AODV) protocol 
which is an enhancement of the well-known AODV protocol for ad-hoc wireless networks. 
SQ-AODV utilizes a cross-layer design approach in which information about the residual 
energy of a node is used for route selection and maintenance. An important feature of SQ- 
AODV is that it uses only local information and requires no additional communication or 
co-operation between the network nodes. SQ-AODV has a proactive route maintenance 
by make-before-break which increases the packet delivery ratio in the network at virtually 
no extra overhead, making it more suitable for ad-hoc wireless environment. SQ-AODV 
is also compatible with the basic AODV data formats and operation, making it easy to 
adopt in ad-hoc networks. 

Simulation results shows under variety of applicable network loads and network pa- 
rameters, SQ-AODV protocol acheives packet delivery ratio, on an average, 10-15% better 
than either AODV or Minimum Drain Rate (MDR) routing protocol, and node expiration 
times 10-50% better than either AODV or MDR, with packet delay and control overhead 
comparable to that of AODV. 

Several directions of future work are possible from here. The first is to combine our 
scheme explicitly with QoS routing, thereby incorporating bandwidth and delay con- 
straints in the path selection process. Another is to consider the effects of mobility and 
fading in our stable routing protocol. 
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Chapter 6 

Introduction to NS-2 



In this appendix, we give a very brief introduction to NS-2. This introduction helps a 
reader to get a basic orientation to NS-2 and enable the reader to better understand the 
implementation details of SQ-AODV given in Appendix 7. 

NS-2 is an object-oriented, discrete event driven network simulator written in C-I--I- 
and OTcl (Object-oriented Tool command language). NS-2 provides substantial support 
for simulating wired and wireless networks with network protocols such as TCP and 
UDP. NS-2 has support for, traffic source behavior such as FTP, Web, CBR and VBR, 
router queue management mechanism such as Drop Tail, RED and CBQ, standard routing 
protocols and Link layer protocols for both wired and wireless networks. 

Although NS-2 is very easy to use once you get to know it, but is quite difficult for 
a beginner. To get a feel of what is NS-2, a beginner is recommended to exercise some 
of the examples given in [12]. One can also find a more detailed documentation of NS-2 
in [13], which is written with the depth of a skilled user. 

A C++ and OTcl Linkage in NS-2 

NS-2 is written in both C-I--I- and OTcl languages, with data path using C++ and control 
path using OTcl. In order to reduce the packet and event processing time, the event 
scheduler and the basic network component objects are written and compiled using C++. 
These compiled objects are made available to OTcl interpreter through OTcl linkage as 
shown in Fig. Al. 

The OTcl linkage creates a matching OTcl object for each of the C++ objects. Thus 
giving the control of the C++ objects to OTcl. There are objects in C++ that do not 
need OTcl control, these objects are not in OTcl space. Similarly there are objects that 
are entirely implemented in OTcl and are not in C++ space. Thus, there is a matching 
OTcl object hierarchy very similar to that of C++. We now give a very brief explanation 
as how NS works. 
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OTcl 




C++ 



Figure Al: C++ and OTcl Linkage in NS-2 

B Simplified User's View of NS-2 

As shown in Fig. Bl, NS-2 is Object-oriented Tel (OTcl) script interpreter that has a 
simulation event scheduler and network component object libraries, and network setup 
helping module libraries. The procedure for simulating a network scenario using NS-2 is as 
follows: User has to write a program using OTcl script language. This program basically 
initiates an event scheduler, sets up a network topology using network component objects 
and helping modules, and tell the traffic sources when to start and stop the transmission 
of packets through the event scheduler. This OTcl script is executed by NS-2 to generate 
the trace of events. The event scheduler will keep track of simulation time and dump 
all the events of the event queue scheduled at the current time, into an output file to 
generate the trace file output. Thus generated trace file is further processed by user 
written scripts to analyze the simulation results. Alternatively, the simulation results can 
also be visualized using Network AniMater (NAM) 



37 



OTcl Script 

Simulation Program 



I 



OTcl : Tel interpreter 
witin 00 extension 

NS-2 Simulator Library 

Event Scheduler Objects 
Network Component Objects 
Network Setup Helping IVIoduies 



I 



Simulation Results 



NAM 

Network Animator 



Analysis 



Figure Bl: Simplified User's View of NS-2 
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Chapter 7 

Details of SQ-AODV in NS-2 



In this appendix, we provide implementation details of SQ-AODV in Network Simulator 
Version-2 [11] (NS-2). We first give the changes made to the AODV routing protocol 
packet formats, and then give the changes made to the functions of AODV to convert 
them into corresponding functions of SQ-AODV. 

A Format of Routing Packets in AODV and SQ-AODV 

The format of the RREQ is as shown in the Figure Al, and contains the following fields: 

• Type - Indicates the type of the packet to differentiate between RREQ, RREP, 
ERROR packets 

• Hop count - The number of hops from originator node to the node handling the 
request 

• BroadcastID - A sequence number uniquely identifying the particular RREQ 
packet when taken in conjunction with originating node's IP address 

• Destination IP address - IP address of the destination for which a route is desired 

• Destination sequence number - The latest sequence number received in the past 
by the originator for any route towards the destination 

• Source IP address - The IP address of the node which originated the RREQ 

• Source sequence number - The current sequence number to be used in the route 
entry pointing towards the source of the route request 

The RREQ packet format modified for SQ-AODV is as shown in Figure A2 and the 
additional fields added are: 

• FlowJd - A sequence number uniquely identifying a flow (for which a route is 
desired) when taken in conjunction with the originator and the destinations IP 
address 
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of a flow 

• Bottleneck life-time - The life-time of the bottleneck node along the path taken 
by the RREQ packet 

In SQ-AODV routing is per session based as against destination-based in AODV. A 
route is uniquely identified by the triple {Src, Dst and FlowJd}, hence the RREQ packet 
carries the fiowJd information to facilitate per session based routing. Session-duration is 
one of the parameters used to admit a new flow, hence this information is also need to be 
carried in RREQ packets to find a route that can survive atleast for the duration of the 
session. For flows not specifying the session-duration, SQ-AODV finds a stable path by 
selecting a path that maximizes the bottleneck node life-time along the path, to facilitate 
this a field is added to carry the bottleneck life-time of the node along a path. 

The format of the RREP is as shown in the Figure A3, and contains the following 
fields: 

• Type - Indicates the type of the packet to differentiate between RREQ, RREP, 
ERROR packets 

• Hop count - The number of hops from originator node to the node handling the 
request 

• Destination IP address - IP address of the destination for which a route is desired 

• Destination sequence number - The latest sequence number received in the past 
by the originator for any route towards the destination 

• Source IP address - The IP address of the node which originated the RREQ 

• Life-time - The time for which nodes receiving the RREP consider the route to be 
valid 

• Timestamp - The time at which the RREP packet has been sent by a node (either 
destination or intermediate) towards the source requesting for a route 

The RREP packet format modified for SQ-AODV is as shown in Figure A4 and the 
fields added are: 

• FlowJd - A sequence number uniquely identifying a flow (for which a route is 
desired) when taken in conjunction with the originator and the destinations IP 
address 

• RCR_fiag - A flag to indicates whether the RREP packet is a Route Change 
Request (RCR) packet or not 
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make-before-break re-routing mechanism of SQ-AODV requires an RCR packet to be 
sent by a node which is about to drain. RREP packet is used as RCR packet by setting 
RCRJlag to 1. The IP address of the node about to drain is sent in place of destination 
sequence number field of RREQ, this information is critical for handling the RCR packet 
in the network. 

The format of the ERROR packet both in AODV and SQ-AODV is as shown in the 
Figure A5, and contains the following fields respectively: 

• Type - Indicates the type of the packet to differentiate between RREQ, RREP, 
ERROR packets 

• Destcount - The number of unreachable destinations included in the ERROR 
packet 

• Unreachable destinations - The IP address of the destinations that have become 
unavailable due to a link break 

• Unreachable destination sequence number The sequence number in the 
route table entry for the destination listed in the Unreachable destination field 

The following fields are added to the ERROR packet format of AODV to use it for 
SQ-AODV: 

• Unreachable source - The IP address of the source, which is part of the triple 
(src/dst/flow_id) identifying a route, got affected due to link failure 

• Unreachable fiowJd - The flowJd of a flow, which is part of the triple (src / dst / fio- 
wJd) identifying a route, got affected due to link failure 

Since the routing in SQ-AODV is per session based, source and flowJd information 
has to be carried as additional information by the ERROR packets to facilitate the route 
maintenance, when a link break due to either mobility of a node or variation in the 
medium occurs. 
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RREQ packet in AODV 




1 Byte, AODV_TYPE 

2 Bytes, Reserved 
1 Byte, Hop-Count 

4 Bytes, Broadcast ID 

4 Bytes, Destination IP Address 

4 Bytes, Destination Sequence Number 

4 Bytes, Source IP Address 

4 Bytes, Source Sequence Number 

4 Bytes, Time stamp 



Figure Al: RREQ Packet Format in AODV 



RREQ packet in SQ-AODV 




1 Byte, AODV_TYPE 

1 Byte, Flowjd 

1 Byte, Session-duration 

4 Bytes, Bottleneck life-time 

1 Byte, Hop-Count 

4 Bytes, Broadcast ID 

4 Bytes, Destination IP Address 

4 Bytes, Destination Sequence Number 

4 Bytes, Source IP Address 

4 Bytes, Source Sequence Number 

4 Bytes, Time stamp 



Figure A2: RREQ Packet Format in SQ-AODV 



42 



RREP packet in AODV 




1 Byte, AODV_TYPE 

2 Bytes, Reserved 
1 Byte, Hop-Count 

4 Bytes, Destination IP Address 

4 Bytes, Destination Sequence Number 

4 Bytes, Source IP Address 

4 Bytes, Life-time of RREP 

4 Bytes, Time stamp 



Figure A3: RREP Packet Format in AODV 



RREP packet in SQ-AODV 




1 Byte, AODV_TYPE 

1 Byte, Flowjd 

1 Byte, RCRJIag 

1 Byte, Hop-Count 

4 Bytes, Destination IP Address 

4 Bytes, Destination Sequence Number 

4 Bytes, Source IP Address 

4 Bytes, Life-time of RREP 

4 Bytes, Time stamp 



Figure A4: RREP Packet Format in SQ-AODV 
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ERROR packet in AODV 

1 Byte, AODV_TYPE 

2 Bytes, Reserved 

1 Byte, Destination Count 

4 X [AODV MAX ERRORS] Bytes, Unreacliable Dests. 

4 X [AODV IVIAX ERRORS] Bytes, Unreacliable Dest. Seq. Nos. 



ERROR packet in SQ-AODV 

• 1 Byte, AODV_TYPE 

• 2 Bytes, Reserved 

■ 1 Byte, Destination Count 

• 4 X [AODV MAX ERRORS] Bytes, Unreacliable Dests. 

■ 4 X [AODV MAX ERRORS] Bytes, Unreacliable Srcs. 

• 1 X [AODV MAX ERRORS] Bytes, Unreacliable flowjds. 

■ 4 X [AODV MAX ERRORS] Bytes, Unreacliable Dest. Seq. Nos. 



Figure A5: ERROR Packet Format in AODV and SQ-AODV 
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When a source node wants to communicate with a destination, the apphcation layer of 
the source node generates data packets and send them to the network layer. In AODV 
or SQ-AODV a packet is received by AODV::recv(Packet *p, Handler *h) function. The 
basic operation of the recv function is depicted in Fig. Bl. 

The source node checks whether a valid route to the destination exists (in SQ-AODV, 
a route is identified by triple src/dst /flowJd) . If a valid route at the source exists then 
data packets are forwarded using this valid route. If a route does not exist the source 
node initiates a route discovery process. The function AODV::rt_resolve(Packet *p) is 
responsible for resolving a route for the data packets and its operation is as depicted in 
Fig. B2. 

A source node initiates a route discovery process by broadcasting a RREQ packet. As 
shown in Figure A2, in SQ-AODV flowJd and session-duration information (if specified) is 
carried in RREQ packet to facilitate a per session based routing, and find routes that last 
for the duration of a session. AODV::sendRequest(nsaddr_t dst) function (AODV::sendR- 
equest(nsaddr_t src, nsaddr_t dst, u_int8_t flowJd) function in SQ-AODV) is responsible 
for broadcasting RREQ packets to 1-hop neighbors, and its operation is depicted in Fig- 
ure B3. 

When an intermediate node receives a RREQ packet the packet is processed by the 
AODV: :recvAODV (Packet *p) function and AODV: :recvRequest (Packet *p) functions, 
whose operation is as depicted in Figure B4, and Figures B5 and B6 respectively. In 
case of SQ-AODV an intermediate node cannot reply to the RREQ packets because, (i) 
the routing is per session based (ii) destination selects a path (among available) which 
maximizes the life-time of the route (iii) applies the Algorithm 1 explained in Chapter 3 to 
forward the RREQ packets. Each intermediate node both in AODV and SQ-AODV sets 
up a reverse route to the previous hop from which the RREQ packet has been received. In 
SQ-AODV the bottleneck life-time field of RREQ packet is updated before re-broadcasting 
the RREQ packet. 

In AODV, when a RREQ packet reaches the destination, node generates a RREP 
packet to reply to this request. On the other hand in SQ-AODV, a destination node 
waits for either 0.25 seconds after the first RREQ arrival or three RREQ packet ar- 
rivals from different paths to reply to a RREQ that maximizes life-time of the path. 
Figure B7 depicts the basic operation of AODV::sendReply(nsaddr_t ipdst, uJnt32_t 
hop_count, nsaddr_t rpdst, u_int32_t rpseq, u_int32_t lifetime, double timestamp) func- 
tion (AODV::sendReply(nsaddr_t ipdst, u_int32_t hop_count, nsaddr_t rpdst, uJnt32_t 
rpseq, uJnt32_t lifetime, double timestamp, uJnt8_t fiowJd, uJnt8_t rcr_fiag) function in 
SQ-AODV) in AODV. An intermediate node receiving this RREP in AODV or SQ-AODV 
will unicast the RREP packet towards the source using reverse route information, and 
sets a forward pointer to the hop from which the RREP has arrived. This forward pointer 
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a node is processed using the AODV::recvReply (Packet *p), and its operation is depicted 
in Figure B8. The source start forwarding data packets once it receives the RREP packet. 



Packet Received 
at Routing Layer 

AODV::recv() 



AODV::initiaiized() 




Figure Bl: Flow-chart of AODV::recv() Function 
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AODV::rt_failed_callback 
rtable.rtJookupO 




Figure B2: Flow-chart of AODV::rt_resolve() Function 



47 



rtable.rtJookupO Forward route 




AODV::PerHopTime() 



Create RREP pkt 



Schedule RREP pkt 



Figure B3: Flow-chart of AODV::sendRequest() Function 




Js pkt a HELLO ?> — ► AODV::recvHello() 



Figure B4: Flow-chart of AODV::recvAODV() Function 
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If 



AODV::id_lookup{) 




AODV::id insertO 



AODV::rt_lookup() 




Figure B5: Flow-chart of AODV::recvRequest() Function 




Figure B6: Flow-chart of AODV::recvRequest() Function 
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rtable.rtJookupO 



Reverse route 



Create RREP pkt 



Schedule RREP pkt 



Figure B7: Flow-chart of AODV::sendReply() Function 




Figure B8: Flow-chart of AODV::recvReply() Function 
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AODV has capabilities of both proactive and reactive route maintenance. Since SQ- 
AODV is an enhancement to AODV it inherits the capabiUties of AODV. Apart from 
these route maintenance capabihties, SQ-AODV has a mechanism of make-before-break 
re-routing. We first explain the basic AODV route maintenance mechanisms and then 
give the make-before-break re-routing feature of SQ-AODV. 

The proactive maintenance in AODV is by periodic hello messages in which every 
node in the network broadcast hello messages to its neighbors every one second. Reactive 
maintenance is done by sending ERROR packets to the sources whenever the link layer 
detects a link breakage. If the reactive maintenance is enabled then proactive maintenance 
(NeighborTimer and HelloTimer) is disabled. 

When a node detects a link failure through link layer feedback it initiates the mainte- 
nance process by broadcasting the ERROR packet to 1-hop neighbors. The AODV::rt Jl_f- 
ailed(Packet *p) function is responsible for the initiation of the maintenance process and 
its operation as depicted in Figure CI. During a route maintenance the route is repaired ei- 
ther through a local repair (if the broken link is near to the destination) or through the ER- 
ROR packets. Local route repair is done using the AODV::locaLrt_repair(aodv_rt_entry 
*rt, Packet *p) function, and its basic operation is as depicted in Figure C2 

In case of the broken link close to the source node the route maintenance is initi- 
ated by the AODV::handle_link_failure(nsaddr_t id) function whose operation is depicted 
in Figure C4. The handle_link_failure function sends an ERROR packet with the help 
of AODV: :sendError (Packet *p, bool jitter=true) function and the basic operation of 
sendError function is depicted in Figure C6. when the ERROR packet finally reaches the 
source of a flow whose route is down due to the link failure, the source node initiates a 
route discovery process to find an alternate route. 

CI Make-Before-Break Re-routing in SQ-AODV 

In this section we explain the details of make-before-break re-routing feature of SQ-AODV. 
To implement make-before-break re-routing mechanism, we have added a timer called 
RCR-timer in the basic AODV code. The RCR-timer expires every 100 msec, and on 
every expiry the AODV::rcr() function is called. The combined operation of RCR-timer 
and rcr function is as depicted in Fig. C8. In rcr function a check is performed to find 
whether the current-energy of the node is less than Threshold-2. If so, a Route Change 
Request (RCR) packet is broadcast to the 1-hop neighbors of this node. 

After receiving a broadcast RCR packet, each neighbor checks whether the drained 
node is the destination or the source or an intermediate node of a route. This check is 
performed for every forward entry in the routing table, and depending on whether drained 
node is source/destination/intermediate node for the flows of neighbors, each neighbor 
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If the drained node is, a destination of any flow in the routing table of the neigh- 
bor indicating its destination has drained, and the neighboring node which received the 
broadcast RCR is a source of the flow then the source node will immediately stop the 
traffic. On the other hand, if the neighboring node which received the broadcast RCR 
is an intermediate node of the flow then this intermediate node sets the RCR-flag in the 
routing table and sends an unicast RCR packet towards the source of the flow. 

If the node from which a broadcast RCR has come happens to be a source for any of 
the routes in the routing table of neighbors then the neighboring node simply free this 
broadcast RCR packet. 

If the node from which a broadcast RCR has come happens to be an intermediate 
node for any of the routes in the routing table of neighbors, and if the 1-hop neighboring 
node is a source of the flow then the source broadcast a RREQ packet to initiate a route 
discovery process. On the other hand, if the node which received the broadcast RCR is an 
intermediate node of a flow then this intermediate node sets the RCR-flag in the routing 
table and sends an unicast RCR packet towards the source of the flow. 

In case of a route with more than one hop an intermediate node has to unicast the RCR 
packet towards the source of the flow. Now, if this unicasted RCR packet has reached 
one more intermediate node of the flow then the intermediate node forwards the RCR 
packet using the reverse route information in its routing table. On the other hand if the 
unicasted RCR has reached a source node of a flow the source node will check whether the 
drained node is the destination or an intermediate node of the flow, if the destination has 
drained then, the source simply stops the traffic, else if an intermediate node has drained 
then source initiates a route discovery process by broadcasting a RREQ packet. 
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Figure CI: Flow-chart of AODV::rt Jl_failed() Function 




AODV::locaLrt_repair() 

T 

rqueue.enqueO 

f 

rtjiags = RT_IN_REPAIR 

T 

AODV::sendRequest() 



Figure C2: Flow-chart of AODV::locaLrt_repair() Function 
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AODV::log link deleteQ 












Delete unreachable node 




from neighbor list 






AODV::handle_link_failure() 




Figure C3: Flow-chart of AODV::nb_delete() Function 




rt->pc_delete{) 
AODV;sendError() 



Figure C4: Flow-chart of AODV::handle_link_failure() Function 




rtjiags = RT_DOWN 

reset the rtable entry 
values to default values 



Figure C5: Flow-chart of AODV::rt_down() Function 




Create ERROR pkt 
Schedule ERROR pkt 



Figure C6: Flow-chart of AODV::sendError() Function 
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Drop(pkt) 



Figure C7: Flow-chart of AODV::recvError() Function 




Broadcast RCR 
(M&drfied RREP) 
packet to 1-hop 
neighbors 



Figure C8: Combined Flow-chart of RCR-timer and RCR function of SQ-AODV 
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Figure C9: Flow-chart of Make-before-break Feature of SQ-AODV 
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